최근 개발자 커뮤니티에서 화제가 된 오픈소스 REA의 등장

최근 AI 코딩 도구를 사용하다 보면 흥미로운 변화가 하나 눈에 띕니다.

예전에는 아이디어를 설명하고 AI에게 코드를 작성해 달라고 요청하는 것이 일반적이었다면,

이제는 이미 만들어진 프로그램을 AI에게 분석하게 하고, 그 프로그램이 어떻게 작동하는지 이해한 다음, 비슷한 기능을 직접 구현하게 만드는 방식으로 발전하고 있습니다.

그 중심에 등장한 프로젝트가 바로 REA(Reverse Engineer Anything) 입니다.

REA는 2026년 10월 초부터 GitHub에서 폭발적인 관심을 받기 시작했습니다.

10월 4일 약 1,500개 수준이었던 GitHub 스타가 10월 16일에는 27만 개를 넘어섰다는 기록이 공개되었고,

npm 다운로드도 10월 초 하루 수백 건 수준에서 10월 12일에는 10만 건 이상으로 증가했습니다.

단순한 관심을 넘어 실제 설치와 사용이 함께 늘어났다는 점에서 주목할 만합니다.

그렇다면 REA는 도대체 무엇일까요?

AI가 기존 앱을 분석해서 소스코드를 복원해 주는 도구일까요? 아니면 Claude Code나 Codex에게 기존 프로그램을 복제하도록 만드는 새로운 기술일까요?

이번 글에서는 REA의 실제 구조와 공개된 사례, 개발자들의 반응, 그리고 우리가 기대할 수 있는 수준과 한계를 살펴보겠습니다.

REA(Reverse Engineer Anything), AI는 이제 완성된 소프트웨어를 역으로 분석하고 다시 만들 수 있을까?

REA는 어떤 오픈소스인가?

REA의 정식 명칭은 Reverse Engineer Anything입니다.

공식 저장소는 GitHub의 morluto/rea이며, MIT 라이선스로 공개된 오픈소스 프로젝트입니다.

REA를 이해하려면 먼저 리버스 엔지니어링이라는 개념부터 살펴볼 필요가 있습니다.

일반적인 소프트웨어 개발은 소스코드를 작성하고 이를 컴파일하거나 실행하여 프로그램을 만드는 과정입니다.

반대로 리버스 엔지니어링은 이미 만들어진 프로그램을 분석하여 내부 구조와 동작 원리를 파악하는 과정입니다.

예를 들어 우리가 사용하는 앱의 소스코드가 공개되어 있지 않더라도, 설치 파일이나 실행 파일을 분석하면 다음과 같은 정보를 얻을 수 있습니다.

• - 어떤 기능들이 구현되어 있는가?

• - 특정 버튼을 누르면 어떤 코드가 실행되는가?

• - 프로그램 내부에서 어떤 함수들이 호출되는가?

• - 어떤 데이터를 읽고 쓰는가?

• - 외부 API나 시스템 기능을 어떻게 사용하는가?

• - 특정 기능의 동작 원리를 다른 프로그램에서 재현할 수 있는가?

• 과거에는 이러한 작업을 수행하기 위해 전문적인 리버스 엔지니어링 지식과 별도의 분석 도구가 필요했습니다.

REA는 이 과정에 AI 코딩 에이전트를 연결합니다.

중요한 점은 REA 자체가 새로운 디컴파일러나 AI 모델을 만드는 프로젝트가 아니라는 것입니다.

REA는 기존의 리버스 엔지니어링 도구들을 AI 에이전트가 활용할 수 있도록 연결하고, 분석 결과를 구조화하여 AI가 다음 분석을 이어갈 수 있도록 돕는

일종의 분석 인프라입니다.

쉽게 말하면 기존에는 개발자가 Ghidra를 열고 직접 프로그램을 분석했다면, 이제는 Claude Code나 Codex에게 분석하고 싶은 기능을 설명하고,

AI가 필요한 분석 도구를 호출하면서 결과를 해석하는 방식으로 바뀌는 것입니다.

REA가 연결하는 주요 도구

REA는 여러 분석 도구를 연결할 수 있습니다.

1. REA가 연결하는 분석 도구들: 디컴파일하면 실제로 무엇을 볼 수 있을까?

REA는 여러 분석 도구를 연결할 수 있습니다. 하지만 각 도구가 분석하는 대상과 결과물은 서로 다릅니다.

특히 실행 파일을 분석하는 도구와 Android 앱을 분석하는 도구는 구분해서 이해할 필요가 있습니다.

이 도구들은 모두 REA 자체에 내장된 기능이라기보다, REA가 분석 대상에 따라 연결하거나 활용하는 외부 도구 및 분석 기능입니다.

공식 문서에서도 분석 대상에 따라 필요한 도구와 환경을 별도로 안내하고 있습니다.

2. Ghidra, IDA, Hopper: 실행 파일을 분석한다는 것은?

먼저 Ghidra, IDA, Hopper를 이해해 보겠습니다.

우리가 일반적으로 개발하는 프로그램은 소스코드에서 시작합니다.

C / C++ 소스코드
       ↓
컴파일러
       ↓
기계어로 변환
       ↓
실행 파일 (.exe, .dll, .so 등)

문제는 실행 파일만 남아 있고 소스코드가 없을 때입니다.

예를 들어 어떤 프로그램이 C++로 만들어졌다고 하더라도, 배포된 실행 파일에는

일반적으로 원래의 변수 이름, 함수 이름, 주석, 클래스 설계 의도 등이 모두 남아 있지 않습니다.

이때 Ghidra, IDA, Hopper와 같은 도구를 사용합니다.

이 도구들은 실행 파일을 분석하여 CPU가 실제로 실행하는 기계어를 사람이 읽을 수 있는 형태로 보여줍니다.

대표적으로 다음 두 가지 결과를 얻을 수 있습니다.

1) 디스어셈블(Disassemble)

기계어를 어셈블리 언어로 변환합니다.

예를 들어 실행 파일에 다음과 같은 기계어가 있다고 가정하겠습니다.

mov eax, 10
add eax, 20
ret

이 코드는 CPU 레지스터에 10을 넣고, 20을 더한 다음 반환하는 동작을 수행합니다.

어셈블리 코드는 실제 CPU가 실행하는 명령에 가까운 형태이기 때문에 프로그램의 동작을 비교적 정확하게 확인할 수 있습니다.

2) 디컴파일(Decompile)

디컴파일은 어셈블리나 기계어를 분석하여 C와 유사한 의사코드로 변환하는 과정입니다.

예를 들어 다음과 같은 결과를 얻을 수 있습니다.

int calculate()
{
    return 10 + 20;
}

이렇게 하면 기계어를 직접 읽는 것보다 프로그램의 동작을 이해하기 쉬워집니다.

다만 여기서 중요한 점이 있습니다.

디컴파일은 원래의 소스코드를 복원하는 과정이 아닙니다.

컴파일 과정에서 변수 이름, 주석, 원래의 코드 구조, 일부 타입 정보 등이 사라졌기 때문에 디컴파일러는 남아 있는 정보를 바탕으로 새로운 형태의 코드를 추론합니다.

따라서 결과는 원래 개발자가 작성한 코드와 다를 수 있습니다.

REA는 이러한 디컴파일 결과와 함수 정보, 문자열, 참조 관계 등을 AI 에이전트가 활용할 수 있도록 연결합니다.

3. Android 앱 분석: JADX와 Apktool은 무엇이 다른가?

Android 앱을 분석할 때는 JADX와 Apktool이 자주 등장합니다.

두 도구 모두 APK 파일을 분석하지만, 목적과 결과물이 다릅니다.

먼저 Android 앱의 구조를 간단히 살펴보겠습니다.

Android APK
 ├─ AndroidManifest.xml
 ├─ classes.dex
 ├─ resources.arsc
 ├─ res/
 │   ├─ layout/
 │   ├─ drawable/
 │   └─ values/
 ├─ assets/
 └─ lib/

여기서 핵심은 classes.dex 와 res입니다.

• - classes.dex: Android 앱의 실행 코드가 포함된 파일

• - res: 앱의 UI, 이미지, 문자열, 레이아웃 등의 리소스

• - AndroidManifest.xml: 앱의 구성, 권한, 액티비티 등의 선언

• - assets: 앱이 사용하는 별도의 파일과 데이터

JADX는 주로 실행 코드 분석에 사용되고, Apktool은 앱의 리소스와 패키지 구조를 분석하는 데 사용됩니다.

JADX: 앱의 로직을 읽는다

https://github.com/skylot/jadx

JADX는 Android APK 또는 DEX 파일을 분석하여 Java 형태의 코드로 보여주는 디컴파일러입니다.

예를 들어 APK 내부에 다음과 같은 코드가 있다고 가정하겠습니다.

public void login(String id, String password) {
    if (id.equals("admin")) {
        openAdminPage();
    }
}

JADX를 이용하면 이와 유사한 형태로 코드를 확인할 수 있습니다.

이를 통해 개발자는 다음과 같은 내용을 분석할 수 있습니다.

• - 앱에 어떤 클래스와 메서드가 있는가?

• - 로그인 기능은 어떤 방식으로 구현되어 있는가?

• - 어떤 API를 호출하는가?

• - 특정 화면에서 어떤 함수가 실행되는가?

• - 앱 내부에서 어떤 데이터를 사용하는가?

• - 특정 기능이 어떤 클래스와 연결되어 있는가?

• - 특히 함수 호출 관계와 코드 참조를 분석할 수 있다는 점이 중요합니다.

예를 들어 로그인 버튼을 누르면 어떤 함수가 실행되고, 그 함수가 다시 어떤 API 호출이나 화면 이동을 수행하는지 추적할 수 있습니다.

물론 실제 앱의 코드가 난독화되어 있거나 복잡하게 최적화되어 있다면 결과가 읽기 어려울 수 있습니다.

Apktool: 앱의 구조와 리소스를 읽는다

https://github.com/iBotPeaches/Apktool

Apktool은 Android APK를 디코딩하여 리소스와 내부 구조를 분석하는 도구입니다.

대표적으로 다음과 같은 결과를 얻을 수 있습니다.

• - AndroidManifest.xml

• - XML 레이아웃

• - 문자열 리소스

• - 이미지 및 Drawable

• - 앱의 리소스 구조

• - Smali 코드

여기서 Smali는 Android의 DEX 바이트코드를 사람이 읽을 수 있는 형태로 표현한 언어입니다.

JADX가 Java와 유사한 형태로 코드를 재구성한다면, Apktool은 Smali 코드와 Android 리소스를 분석할 수 있도록 제공합니다.

특히 Android 앱의 UI를 분석할 때 Apktool이 유용합니다.

예를 들어 다음과 같은 정보를 확인할 수 있습니다.

• - 특정 화면의 XML 레이아웃

• - 버튼이나 텍스트의 리소스 ID

• - 이미지 파일과 아이콘

• - 앱에서 사용하는 문자열

• - 액티비티와 권한 선언

• - 리소스와 코드 사이의 연결 정보

4. JADX와 Apktool을 함께 사용하면?

두 도구는 경쟁 관계라기보다 서로 보완적인 관계입니다.

예를 들어 어떤 Android 앱의 로그인 화면을 분석한다고 가정해 보겠습니다.

JADX를 사용하면 로그인 버튼을 누른 뒤 어떤 함수가 실행되고, 어떤 인증 API를 호출하는지 확인할 수 있습니다.

반면 Apktool을 사용하면 로그인 화면의 XML 구조와 이미지, 문자열 리소스 등을 확인할 수 있습니다.

두 결과를 함께 활용하면 화면의 구성과 실제 동작을 더 구체적으로 이해할 수 있습니다.

REA가 Android 분석을 지원할 때도 이러한 코드 분석과 리소스 분석을 구분하여 활용합니다.

공식 설치 안내에서도 APK 분석에는 JADX, Android 리소스 분석에는 Apktool을 각각 별도로 안내하고 있습니다.

REA의 가장 중요한 특징: Evidence, 즉 분석 증거를 기록한다

REA를 살펴보면서 개인적으로 흥미로웠던 부분은 Evidence라는 개념입니다.

REA는 단순히 분석 결과를 텍스트로 반환하는 것이 아니라, 분석 과정에서 확인한 내용을 구조화된 Evidence 형태로 관리합니다.

이 Evidence에는 다음과 같은 정보가 포함될 수 있습니다.

• - 어떤 분석 도구를 사용했는가?

• - 어떤 프로그램이나 파일을 분석했는가?

• - 어떤 함수 또는 코드 위치를 확인했는가?

• - 실제로 관찰된 사실은 무엇인가?

• - 그 사실을 바탕으로 어떤 결론을 내렸는가?

• - 분석 과정에서 확인하지 못한 부분은 무엇인가?

• - 어떤 한계나 불확실성이 존재하는가?

예를 들어 AI에게 다음과 같이 요청했다고 가정하겠습니다.

"이 게임에서 공이 벽돌에 부딪힐 때 사운드의 위치가 어떻게 계산되는지 분석해 줘."

일반적인 AI라면 게임의 소스코드를 모르는 상태에서 비슷한 기능을 추측하여 설명할 수 있습니다.

REA를 사용하면 실제 실행 파일에서 관련 함수를 조사하고, 그 함수의 어셈블리나 디컴파일 결과를 근거로 분석할 수 있습니다.

이 과정에서 REA가 제공하는 Evidence는 AI가 자신의 결론을 뒷받침하는 데 활용됩니다.

즉, 단순히 "이 함수는 사운드 위치를 계산합니다"라고 설명하는 것보다, 실제로 어떤 코드와 분석 결과를 확인했는지 함께 기록할 수 있습니다.

REA 공식 문서에서는 분석 결과의 근거와 한계를 보존하고, Evidence를 다른 분석이나 설명에서 참조할 수 있도록 설계했다고 설명합니다.

1. Evidence는 영수증과 비슷한 개념일까?

질문한 '영수증'이라는 표현은 상당히 적절한 비유입니다.

다만 REA에서 공식적으로 사용하는 개념은 영수증(Receipt)이 아니라 Evidence(증거) 입니다.

영수증이 구매한 상품과 결제 금액, 거래 시점 등을 기록하는 것처럼, REA의 Evidence는 분석 과정에서 확인한 사실과 근거를 기록합니다.

하지만 일반적인 영수증과 달리 분석 결과의 출처, 코드 위치, 관찰 내용, 한계 등을 포함할 수 있습니다.

예를 들어 다음과 같은 형태로 이해하면 됩니다.

[분석 대상]
DX-Ball 실행 파일

[조사 항목]
사운드 위치 계산 함수

[확인한 사실]
공의 좌표를 이용해 사운드 위치를 계산함

[근거]
원본 실행 파일의 함수 분석 결과
관련 어셈블리 및 디컴파일 결과

[검증]
재구성한 코드와 원본 함수의 결과 비교

[한계]
게임 전체의 사운드 시스템을 분석한 것은 아님

위 내용은 이해를 위한 예시이며 실제 Evidence JSON의 필드 구성이나 출력 형식 그대로는 아닙니다.

실제 REA의 Evidence는 CLI 및 MCP에서 구조화된 결과로 제공되며, evidence_id를 이용해 분석 결과를 참조할 수 있습니다. 분석이 불완전하거나 추가 확인이 필요한 경우에는 한계와 남아 있는 불확실성도 함께 관리할 수 있습니다.

2. 왜 이 기능(영수증)이 중요한가?

이것은 AI 개발에서 상당히 중요한 차이를 만들어낼 수 있습니다.

AI가 코드를 작성하는 것 자체는 이제 특별한 일이 아닙니다.

하지만 AI가 기존 프로그램을 분석한 뒤 다음과 같이 설명한다면 이야기가 달라집니다.

"이 기능은 원본 프로그램의 특정 함수에서 확인했습니다. 해당 함수는 다음과 같은 계산을 수행하며, 이 부분은 실제 코드에서 확인했습니다.

다만 네트워크 서버에서 처리되는 부분은 분석하지 못했기 때문에 이 부분은 추론입니다."

이러한 방식은 AI의 설명을 검증할 수 있도록 합니다.

결국 REA가 지향하는 방향은 단순히 AI가 더 많은 코드를 작성하도록 만드는 것이 아니라,

AI가 실제로 확인한 사실을 근거로 소프트웨어를 이해하고, 그 이해를 바탕으로 새로운 기능을 구현하도록 만드는 것에 가깝습니다.

다음 글에서는 레딧에서 실제 반응이나 유저 리뷰를 바탕으로 가능성과 현실에 대해 말해볼게요